Cómo briefar un rediseño web para que diseño, tecnología y medición vayan juntos
Un brief de rediseño web se queda corto cuando el encargo se reduce a un cambio de aspecto. El brief útil deja por escrito el objetivo de negocio, quién lo aprueba, qué sistemas hay que respetar y cómo se va a medir el sitio el día de la publicación.
En dobleO vemos briefs que llegan como un moodboard y un plazo. El diseño puede salir bien y, aun así, el proyecto se atasca en integraciones, idiomas, analítica o en una plataforma que nadie ha decidido mantener. Este texto es un checklist para quien prepara un brief interno o un RFP: marketing, tecnología y medición en el mismo documento.
En resumen
- El brief no es un documento de estilo. Es el acuerdo de alcance entre negocio, diseño, tecnología y analítica.
- Hacen falta, como mínimo, marketing, sistemas, marca y quien vaya a publicar. Legal entra cuando hay datos, sectores regulados o varias sociedades.
- Pide en discovery un inventario de plantillas, un mapa de conversión y una foto de la medición actual.
- Evalúa la propuesta por el proceso y por lo que queda escrito, no solo por los mockups.
Ese acuerdo es el arranque de un diseño y desarrollo web: objetivo, sistemas y medición antes de pedir pantallas.
Un brief de rediseño web, ya rellenado
El índice solo ordena. Lo que se puede juzgar es un brief ya contestado, aunque sea de un caso imaginario. Sirve para calibrar el nivel de concreción. Si el vuestro cabe en menos líneas, todavía está en moodboard.
Objetivo: conseguir reuniones cualificadas con dirección de marketing y de sistemas de empresas que ya tienen web y van a renovarla o a abrir un ecommerce en varios idiomas. No es “mejorar la imagen”. El éxito a noventa días es que el formulario de contacto llegue con empresa, rol y tipo de proyecto, y que quien lo recibe pueda preparar la llamada sin pedir esos datos otra vez.
Quién aprueba: dirección digital aprueba el alcance. Sistemas aprueba plataforma, entornos y accesos. Marca aprueba el sistema visual. Quien publica —dos personas, no un departamento— aprueba que puede sacar una página de servicio sin abrir un ticket. Legal entra si el formulario guarda datos personales, que los guarda. El calendario nombra a esas personas. “Stakeholders” no es un nombre.
Lo que ya existe
Qué existe: un sitio en el CMS habitual, dos idiomas que no son calco, un formulario que escribe en un buzón y no en un CRM, y una analítica que cuenta visitas y poco más. Hay un partner de medios y otro de SEO. No se les sustituye. Hay que sentarlos antes de cerrar tipos de URL y antes de publicar. El área de clientes no entra en esta fase. Si aparece en una pantalla, es un cambio de alcance.
Plantillas y medición de esta fase
Plantillas de esta fase: home, servicio, artículo, contacto, y una landing que medios pueda repetir. El archivo de artículos se mantiene con la plantilla nueva y sin rediseño artículo a artículo. Idiomas: los dos actuales, con hreflang y con un flujo de traducción que no bloquea la publicación del idioma principal. Integraciones: el formulario pasa al CRM que sistemas ya tiene, con los campos de la discovery. Nada de catálogo de productos en esta fase.
Medición: inventario de lo que hoy se considera conversión —hoy es “visita a gracias”, y se quiere pasar a “el servidor aceptó el formulario”—. Eventos con nombre estable, sin datos personales en el analítico. Comprobación las primeras setenta y dos horas, con el partner de analítica si ya existe. Rendimiento: umbral en home, servicio y contacto, medido en preproducción con los terceros que de verdad se van a cargar. No un cien en todo el dominio.
Arquitectura y lo que queda fuera
Un brief así se lee también en la arquitectura, el rendimiento y la infraestructura: si el CMS aguanta esas plantillas, si el entorno de pruebas no escribe en producción, si el peso de la home cabe en el umbral, si el evento vive en la plantilla y no en un texto que el editor va a cambiar. El brief se redacta para que marketing y sistemas puedan decidir con el mismo papel delante. Diseño dice si el sistema visual cabe en esas plantillas. SEO y SEM dicen si las URLs y las landings se pueden sostener. Cuentas comprueba que las personas nombradas existen y tienen hueco en el calendario.
Lo que queda fuera se escribe con la misma tinta: app, área de clientes, tercer idioma, migración de mil fichas de producto. Fuera no significa nunca. Significa que no se dibuja ni se presupuesta ahora. Cuando el brief de un proveedor real baja de este grano, la primera sesión no es de diseño. Es de volver a escribir estas líneas con quien decide.
Qué tiene que decir el anexo técnico, además del objetivo
El brief de negocio dice para qué existe el sitio. El anexo técnico dice cómo se va a poder construir sin descubrir el sistema el día que se aprueban las pantallas. Cabe en pocas páginas y se escribe con sistemas en la mesa. Si no está, cada propuesta rellena el hueco con la plataforma que esa agencia ya tiene montada.
Entornos. Hace falta nombrar producción, preproducción y, si existe, el entorno donde se prueban integraciones. Preproducción no indexa: noindex y, cuando el dominio de pruebas es público, un control de acceso. No comparte base de datos con producción. Un formulario de prueba no puede crear un contacto real en el CRM. El despliegue se describe en una frase operativa: el código entra por el repositorio, la publicación de contenido la hace el editor en el CMS, y una no pisa a la otra. Si hoy se edita por FTP sobre el servidor, el anexo lo dice. Es un dato, no una vergüenza. Cambia el plan de la primera semana.
Mapa de redirecciones
Mapa de redirecciones. Columnas mínimas: URL de origen, URL de destino, código (casi siempre 301 cuando la página se retira de forma definitiva; 302 solo si la retirada es temporal), y si se conservan los parámetros de campaña. Se agrupa por plantilla, no se pega un export crudo de diez mil filas sin dueño. Las cadenas —A redirige a B y B redirige a C— se cortan antes de apagar el sitio viejo. El partner de SEO puede ser quien valida el destino. El equipo que construye es quien las implementa y quien comprueba que no quedan bucles. Sin ese archivo, el rediseño “conserva el SEO” solo en la portada de la propuesta.
Integraciones. Para cada una: sistema de destino, qué dato cruza, en qué momento (al enviar el formulario, al publicar, en un proceso nocturno), cómo se autentica y dónde vive el secreto. El secreto no va en el tema ni en el JavaScript del navegador. También se escribe el fallo: qué ve la persona si el CRM no responde, y si el envío se reintenta o se guarda. Un timeout sin mensaje es un lead perdido que el informe de analítica puede contar como éxito si el evento se disparó en el clic y no en la respuesta del servidor.
Caché y peso
Caché y peso, en el mismo anexo, sin convertirlos en una auditoría. Qué plantillas pueden cachearse enteras en el CDN y cuáles no, porque llevan un área con sesión. La cabecera lo dice (Cache-Control público frente a privado). Qué terceros se cargan en la home y en la landing, y si alguno es necesario para el primer pintado. El anexo cierra la arquitectura, el rendimiento y la infraestructura: entornos que no escriben en producción, redirecciones que no encadenan, secretos fuera del front, caché que no guarda páginas con sesión, y un peso de plantilla que el diseño todavía puede cumplir. El brief se redacta para que marketing y sistemas firmen el mismo alcance, con el objetivo comercial en la primera página y estas condiciones en el anexo.
Quién tiene que estar en la mesa
No hace falta sentar a veinte personas. Hace falta que las decisiones no las tome un solo departamento y las pague otro.
| Rol | Qué aporta al brief | Qué se atasca si falta |
|---|---|---|
| Marketing o dirección digital | Objetivo, audiencias, páginas que tienen que convertir, mensaje | Un sitio correcto y sin prioridad comercial |
| Sistemas o IT digital | CMS, hosting, integraciones, seguridad, entornos | Un diseño que no se puede implementar o mantener |
| Marca | Sistema visual, tono, activos que ya existen | Una web desconectada del resto de la marca |
| Quien publica | Flujo real de contenidos, idiomas, aprobaciones | Una herramienta que el equipo no usa |
| Legal, cuando aplica | Datos, consentimiento, claims, filiales | Un go-live bloqueado |
Si el proyecto es de grupo o de varias filiales, añade quién aprueba el alcance común y qué puede variar por país. Esa línea evita rediseñar ocho veces la misma plantilla.
Dos propuestas encima de la mesa
Imagina dos documentos llegados al mismo brief. No son ofertas reales. Sirven para ver qué se compara.
La primera abre con tres pantallas de la home y un precio único. El plazo son ocho semanas. La analítica aparece como “configuración de herramientas”. No hay inventario. La plataforma es la que la agencia usa siempre, mencionada como si fuera un requisito del cliente. El equipo es “un equipo multidisciplinar” sin nombres ni oficios.
La segunda abre con lo que ha entendido del objetivo y con lo que todavía es un hueco. Separa discovery, diseño del sistema, construcción por plantillas, medición y handoff. Dice qué partner externo hay que sentar en dos momentos: URLs antes de construir, y eventos antes de publicar. Nombra especialidades. El alcance nombra esa lista y dice qué queda fuera, por ejemplo el área de clientes o un idioma nuevo.
Quien compara puede preferir las pantallas de la primera. Aun así, no está comparando el mismo objeto. La primera vende una hipótesis visual. La segunda vende un proceso para llegar a un alcance. Si el RFP obliga a las dos a contestar las mismas preguntas —inventario, idiomas, eventos, quién mantiene—, la primera tiene que enseñar el mismo esqueleto o quedar en blanco. Ese es el sentido del brief: impedir que gane el documento más brillante y menos operable.
En dobleO la segunda forma es la que sabemos escribir, con diseño, desarrollo, rendimiento, SEO técnico y analítica en el mismo proyecto, y con sitio para los partners que ya están. La arquitectura, el rendimiento y la infraestructura van en el mismo papel. El brief se redacta para que marketing y sistemas puedan decidir con ese papel delante.
Cómo leer una propuesta
Una propuesta seria separa descubrimiento, diseño, construcción, medición y entrega. Nombra quién hace cada parte dentro del equipo y cómo se coordina con las agencias que ya están en SEO, medios o analítica.
Señales útiles en el documento:
- El alcance está escrito por módulos, con lo que entra y lo que no entra.
- Hay un criterio de plataforma, no una preferencia disfrazada de requisito.
- La analítica forma parte del proyecto, con una comprobación después de publicar.
- El handoff incluye documentación para el equipo interno.
- Los casos muestran proceso. No hace falta una cifra de retorno para que un caso sea creíble.
Desconfía, en cambio, de un presupuesto cerrado sobre un moodboard, de un plazo milagro y de una garantía de posiciones. Eso no es un alcance. Es una frase comercial.
Preguntas frecuentes
¿El brief lo escribe marketing o lo escribe la agencia?
Lo escribe quien encarga el proyecto, con los huecos a la vista. La agencia puede ayudar a completarlo en discovery. Si la agencia redacta el brief entero antes de hablar con sistemas, el documento suele ignorar la plataforma y la medición.
¿Hace falta un RFP formal?
No siempre. En una empresa con compras, el RFP compara agencias con las mismas preguntas. En un encargo directo, un brief interno con el mismo índice basta. Lo que no basta es un correo de una línea.
¿Cuándo entra Legal?
Cuando hay datos personales, claims regulados, varias sociedades o un sitio que no puede publicarse sin revisión. Meter a Legal el día anterior al go-live convierte el checklist en un bloqueo.
Siguiente paso
Cuando el brief ya nombra objetivo, plataforma y medición, el acuerdo siguiente es qué página sostiene cada fase del recorrido.
Eso se cierra en discovery, como parte del desarrollo web.
Siguiente en este ciclo: arquitectura y conversión en una web B2B.
Diego Quiñones · Technical Growth Architect en dobleO (Madrid). Arquitectura web, rendimiento, SEO técnico e infraestructura, junto al equipo de diseño, SEO y SEM, cuentas y dirección. Con el equipo dobleO.
